home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 1 / ETO Development Tools 1.iso / Essentials / MacApp Documentation / MacApp AppleLink Messages / MacApp.Tech$ Oct 89 / Z0205-Re More Eiffel Stuf-Oct89 < prev    next >
Encoding:
Text File  |  1989-10-31  |  3.5 KB  |  77 lines  |  [TEXT/GEOL]
  1. Item    5107515                         30-Oct-89        13:57
  2.  
  3. From:   D1282                           Power Up,PRT
  4.  
  5. To:     D2022                           Strata, Gary Bringhurst,PRT
  6.  
  7. cc:     MACAPP.TECH$                    MACAPP Tech
  8.  
  9. Sub:    Re-More Eiffel Stuff
  10.  
  11. Dear Mr. Bringhurst,
  12.  
  13. Thank you for your recent link regarding Eiffel (Item 1309297, 89/10/17,
  14. 18:57).  I apologise for my slow response; the earthquake shook me up a little,
  15. and my wife had a baby last week, which also occupied rather a lot of my time.
  16.  
  17. Your link mentioned three topics that I would like to respond to:  garbage
  18. collection in Eiffel, protected members (as in C++), and inline substitution in
  19. Eiffel.
  20.  
  21. As to garbage collection, I agree whole-heartedly that garbage collection can
  22. be a good thing; I would go so far as to say that elegant, small,
  23. well-implemented garbage collection would be a great boon to programmers
  24. everywhere.  I've chased down too many bugs related to memory management to
  25. feel otherwise.  I have some doubts as to how well Eiffel's garbage collection
  26. algorithms will meld with the Mac's memory management.
  27.  
  28. You mention that you like C++'s protected class members (features), saying
  29. "[t]here are many occasions when a class designer may want to make a facility
  30. available to descendents, but not to other clients."
  31.  
  32. First, as a minor matter of semantics, let me point out that a descendant is
  33. not a client, nor vice versa.  A descendant of class Foo has an "is-a"
  34. relationship with Foo, while a client has a "has-a" relationship with Foo.
  35.  
  36. As to the matter of Eiffel's lack of a protected mode, I am confused.  Can't
  37. the class designer simply not export the features she wishes to hide from the
  38. client?  If the designer wishes to hide one of Foo's features (say, Bar) from
  39. its clients, then the designer need only exclude Bar from Foo's export clause,
  40. and voila — no client of Foo can access Bar.  However, all descendants of Foo
  41. can access all of the features of Foo, exporting them or not as they see fit.
  42. This issue is discussed in Meyer's book, in section 11.5 (Inheritance and
  43. Information Hiding), found on pages 272-274.  This section also emphasizes the
  44. difference between a client and a descendant — a distinction missing from your
  45. link, as mentioned above.
  46.  
  47. It would appear from the discussion in Meyer's book that Eiffel's mechanism
  48. (including selective exports) is both simpler and more powerful that C++'s
  49. private, public, and protected modes.  If you have a counter-example, which
  50. shows C++'s mechanism to be superior or even equal, I would love to see it.
  51. If, similarly, you can present any other arguments against the Eiffel
  52. inheritance/export clause mechanism, I would like to see those, too.  This is
  53. not an area of Eiffel that I have explored to any great depth, and I would like
  54. to hear the comments of others on it, especially as it relates to C++.
  55.  
  56. Lastly, you mention that you are "also uncomfortable with the inline
  57. substitution technique referenced in the Eiffel documentation."  I'm afraid
  58. you've got me by the short hairs on this one — what inline substitution
  59. technique are you refering to?  What are its weaknesses, as you see them, that
  60. make you uncomfortable?  What do you see as alternatives, and what advantages
  61. do they have over the Eiffel technique?
  62.  
  63. Thanks again for your link.  I'm looking forward to your response to this one.
  64. Until then, I will remain
  65.  
  66.  
  67. Yours,
  68.  
  69. James Plamondon
  70. Software Engineer
  71. PowerUp! Software
  72. 2929 Campus Drive, Suite 300
  73. San Mateo, CA  94403
  74. (415) 345-5900 x351
  75. AppleLink: D1282
  76.  
  77.